This disclosure relates generally to the field of computer databases. More particularly, but not by way of limitation, it relates to a technique for extending a database recovery point at a disaster recovery site.
Computer databases have been an important part of enterprises for decades. Two major types of computer databases are hierarchical databases and relational databases. Hierarchical databases, which were developed prior to relational databases, are arranged in tree-like hierarchical structures representing logical relationships. Relational databases organize data into tables of rows and columns. One common relational database management system (DBMS) is the DB2® database system marketed by International Business Machines Corporation (IBM). (DB2 is a registered trademark of IBM.)
With the increasing importance of information technology for the continuation of business critical functions, combined with a transition to an around-the-clock economy, the importance of protecting an organization's data and IT infrastructure in the event of a disruptive situation has become an increasing and more visible business priority in recent years. Backup sites are commonly established by enterprises where a copy of a database can be accessed as needed, such as when circumstances prevent access to the original database. These backup sites are commonly referred to as disaster recovery sites, because they may come into operation in the event of a natural or human-made disaster, allowing recovery of systems that are affected by the disaster.
Disaster recovery sites are typically established at some distance from the original or local site, to attempt to avoid a situation where a disaster may affect an entire area, although some enterprises may set up disaster recovery sites that are relatively nearby the local site.
Some disaster recovery sites, typically referred to as a “hot site,” attempt to duplicate the original site of the organization, with full computer systems as well as near-complete backups of user data. Real time synchronization between the two sites may be used to mirror the data environment of the original site using wide area network links and specialized software. The goal of a hot site is to allow the organization to relocate operations with minimal losses to normal operations. This type of disaster recovery site is very expensive to operate, but may be necessary for organizations that operate real time processes such as financial institutions, government agencies and ecommerce providers.
Other disaster recovery sites, typically referred to as a “cold site,” may provide little more than a space already configured for use in a disaster, but without any of the hardware or software that might be necessary for a recovery operation. While relatively inexpensive, a cold site may require extensive downtime to install the necessary equipment and software, in addition to the time required to restore operational data.
A “warm site” is a compromise between a hot site and a cold site. A warm site may already have hardware and software resources installed and ready for use, but typically does not mirror the local site in real time, and depends on restoring backups that may not be completely current with respect to the local site. Warm sites typically depend upon periodic backups of data. In some warm sites, the backups are physically trucked or otherwise delivered to the warm site, while in others, the backups are electronically transmitted to the warm site, at a lower cost than real-time synchronization.
In such a disaster recovery site, how current the backup is depends on how frequently the backups are performed. In some sites that use DB2 databases, the disaster recovery procedures periodically pre-generate jobs that can be run at the disaster recovery site to bring the remote database up to the time that the recovery job was generated at the local site. Transactions that occurred after the pre-generated job was created are typically logged in archive logs that could be delivered to the disaster recovery site to make the recovery site database more current, but those archive logs are not taken into account by the pre-generated job, because it was created before the additional archive logs. Thus, the database is recovered at an older state than desired. Although manual steps may be taken to add the archive log information to the recovered database, such manual steps may take long amounts of time and afford significant risks of errors, particularly in the heightened pressure of a disaster recovery event. Database administrators (DBAs) have long desired an automatic procedure that would allow recovering databases beyond the periodic pre-generated recovery point.